The IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session.
FIG. 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network (IMS can of course operate over other access networks). As shown in FIG. 1, the IMS includes a core network, 101, and a service network, 102. Call/Session Control Functions (CSCFs), 103, operate as Session Initiation Protocol (SIP) proxies within the IMS core network, and interface with other entities such as Breakout Gateway Control Functions (BGCFs), 104, and Media Resource Function Controllers (MRFCs), 105, amongst others. A Proxy CSCF (P-CSCF) is the first point of contact within the IMS for an SIP terminal; a Serving CSCF (S-CSCF) provides services to the subscriber; an interrogating CSCF (I-CSCF) identifies the correct S-CSCF and forwards to that S-CSCF a request received from an SIP terminal via a P-CSCF.
Situations may arise in which a user, participating in a communication session with another user, wishes to place the other user on hold. 3GPP has specified a Communication HOLD supplementary service in TS 24.610, where a user can put another user on HOLD by changing the direction of the media stream in an established communication as defined in chapter “4.5.2.1 Actions at the invoking UE.” In such a case a User Equipment (UE) generates a new session description protocol (SDP) offer, in which the SDP offer contains an attribute specifying the desired change. If the direction of the media stream was initially set to “send and receive,” it may be downgraded to “send only” by specifying a “sendonly” attribute in the SDP offer. If the direction of the media stream was initially set to “receive only,” it may be changed to “inactive” by specifying an “inactive” attribute in the SDP offer. The user can later resume the communication by changing back the media direction. A “recvonly” SDP attribute is used when the stream was previously set to “inactive,” and a “sendrecv” SDP attribute is used when the stream was previously set to “sendonly.” However the latter attribute may be omitted, since “sendrecv” is the default.
Chapter “4.5.2.4 Actions at the AS of the invoking UE” of TS 24.610 states that it is a network option as to whether to provide an announcement towards the held user.
There may be circumstances in which it is undesirable to have a HOLD announcement provided by a network when the user changes a direction of the media stream. For example, the user may be participating in a media session, containing both video and audio streams, with another node in a terminating network. Due to bandwidth considerations the user may decide to stop receiving the video stream, but keep the audio stream. In such a case the user may specify that the video stream direction be changed from “send and receive,” to “send only.” In this example, the user would not want an Application Server (AS) to provide a HOLD announcement to the other node in response to this change in direction of the media stream.
A specification is defined for the use of withholding a HOLD announcement during a conference, and is given in TS 24.610, chapter 4.6.6. If a participant of a conference invokes the HOLD service, it is not desirable to provide an announcement to the conference. The AS configures a HOLD announcement when a request is made to change the direction of the media stream during a conference, and does not provide one to the held users when the request originates from the “focus,” with the “focus” being the central point of control, authentication, and authorization of the conference.
The withholding of the HOLD announcement specified in TS 24.610 does not solve the problem of allowing a user to configure a HOLD announcement, which is to be implemented when the user makes a change to the direction of the media stream.